Yes, like discussed:

• We could either close this one and leave it as is, because there are no high frequency releases
• Or we approve this one and it deviates. But I'm not aware of any dependents which this may have an effect on
• OR... we create some kind of sophisticated update scripts/ci which reflect the the version of logrotate when being changed. This would be achievable through a so called Release-As commit on the release-please PR. But that introduces a considerable amount of complexity and edge cases.

What I mean is, if we deviate from the logrotate version, that's fine, but then we need to pick another version aside from 3.21.0 as a starting version here (in .github/config/.release-please-manifest.json). The problem is that if that we don't, for the first releases it would create a false impression that we're still following the logrotate's version (like 3.21.1, 3.21.2 etc.)

Then I'd say we bump to the next major version to clearly differentiate here.
It's possible like described in here: https://github.com/camunda/infra-actions-runner/pull/23#issuecomment-2446186173

For completeness:
We will bump to 4.0.0 with the next release:

• chore(master): release 4.0.0 #23